fix(lock): don't dereference a NULL locker in the priority accessors (#148) - #154

Fixes #148.

DB_ENV->set_lk_priority() and DB_ENV->get_lk_priority() crashed the library on a
plain public-API call naming a locker id with no live locker:

  db_env_create(&e, 0);
  e->open(e, path, DB_CREATE|DB_INIT_LOCK|DB_INIT_MPOOL|DB_INIT_TXN|DB_INIT_LOG, 0600);
  e->set_lk_priority(e, 0, 100);   /* SIGSEGV */

__lock_getlocker() with create == 0 reports 'no such locker' by returning 0 with
a NULL locker rather than by returning an error -- its only assignment to *retp
is at lock_id.c:408, after the 'if (sh_locker == NULL && create)' block. Both
accessors tested only 'ret == 0' and then dereferenced. gdb:

  Program received signal SIGSEGV
  #0  __lock_set_lk_priority (priority=100) at ../src/lock/lock_method.c:483
  #1  main () at r.c:13

Both now return EINVAL for a missing locker. The check is deliberately local to
these two functions rather than a change to __lock_getlocker()'s contract:
__lock_vec_pp() passes the same possibly-NULL locker into __lock_vec(), which
handles it on purpose ('it's perfectly reasonable for there to be no locker;
this is not an error'), so tightening the shared helper would break a caller that
depends on the current behavior. The original report suspected __lock_vec_pp()
was affected too; it is not, and I verified that by calling lock_vec() with
DB_LOCK_PUT_ALL and DB_LOCK_UPGRADE_WRITE on an unused id -- both return 0.

Regression test test/db/lock_priority_nullderef.c covers all three cases: EINVAL
for the setter and getter on an unused id, and a set/get round trip on a LIVE
locker so the fix cannot regress into simply disabling the feature. Proven to
have teeth: reverting the two checks makes the runner report FAIL (rc=139,
Segmentation fault). Wired into the CI regression-runner step.

Found by the coverage-driver work in #147, which SIGSEGVed on the never-called
getter surface.